REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

Hi @rashigupt ! Thanks for the development. I just have a doubt from my side: why using a gap-triggered configuration if you disable all HF decays? Why can't you use a standard generator?

hi @stefanopolitano, Yes, I disabled all HF decays while producing the enhanced sample because I want to generate enhanced pion and eta statistics in order to obtain a sufficient number of non-heavy-flavour (background) electrons. When I used the general-purpose dataset, the statistics for Non-HFE were too low.

Hello @rashigupt , I see from your PR that you have GeneratorHF_Non_Hfe_enhance.ini, but GeneratorHF_Non_Hfe.C as test. This will not work because the CI will check a .C macro named in the same way as your ini file. Could you please rename the test?

Hi @rashigupt ! Sorry for the late response, but I think I am not getting your point. For my understanding, if you want pions and eta not coming from HF, what is the point of using gap trigger to include ccbar/bbbar events?

Hello @rashigupt , I see from your PR that you have GeneratorHF_Non_Hfe_enhance.ini, but GeneratorHF_Non_Hfe.C as test. This will not work because the CI will check a .C macro named in the same way as your ini file. Could you please rename the test?

ok

Hi @rashigupt ! Sorry for the late response, but I think I am not getting your point. For my understanding, if you want pions and eta not coming from HF, what is the point of using gap trigger to include ccbar/bbbar events?

Hi, sorry for the late reply. You're right — using a gap trigger doesn't make sense for non-HFE pions and η. I've updated the code and created a separate file without the gap trigger for the non-HFE case.

Dear all, please apprvoe and merge this code.

Hi @rashigupt could you please fix the test?

Following INI files will be tested:
  - /O2DPG/MC/config/PWGHF/ini/GeneratorHF_Non_Hfe.ini
Checking /O2DPG/MC/config/PWGHF/ini/GeneratorHF_Non_Hfe.ini
Test 0: /O2DPG/MC/config/PWGHF/ini/GeneratorHF_Non_Hfe.ini with generator External�[0;31m -> FAILED�[0m
�[0;31mError found in log /sw/BUILD/d863a04800afcfe7c5f10c292ee38e8aeb3fff02/O2DPG-sim-tests/o2dpg-sim_tests/o2dpg_tests/generators/0_GeneratorHF_Non_Hfe.ini_External_dir/o2dpg-test-kine.log�[0m
21---------------------------------
22-# Events: 100
23-# MB events: 80
24-# events injected with 1 quark pair: 7
25-# events injected with 2 quark pair: 7
26-# events injected with 3 quark pair: 6
27-# 1 (anti)quarks: 4680
28-# 2 (anti)quarks: 5370
29-# 3 (anti)quarks: 1677
30-Number of generated events injected with 1 different than expected
31:(int) 1

This is the current error making the CI fail

Hi, @jackal1-66 ,I’m still not sure how to fix this. Could you please guide me?

Hi, @jackal1-66 ,I’m still not sure how to fix this. Could you please guide me?

Ciao @rashigupt I had a look at your test. I think the problem is that you're assuming nEventsInjOne, and other counters should be half of the total injected events, while in reality the factor is 1/3 (considering 3 quarks species by default). This should fix the problem you're experiencing in the CI

hi @jackal1-66 , Thank you for the suggestion.

hi @jackal1-66 , I updated the text file as suggested, using the 1/3 factor instead of 1/2 for the event counters. However, the CI is still failing with the same error.

Ciao @rashigupt,
Two things:

• Replace 1/nInjectedSpecies with 1./nInjectedSpecies → there's a cast error in the modification you committed
• Increase the tolerance to 10%, currently the last test is bound to fail (100 events generated, only 6 triggered with 3 quarks and the tolerance is 6.33)

Thank you @jackal1-66 for your comments.
I have addressed both points by fixing the cast issue (1./nInjectedSpecies) and increasing the tolerance to 10% as suggested.
With these changes, the CI tests are now passing and the issue is resolved.
I would appreciate it if you could approve and merge the changes.

@stefanopolitano can you check this out? Missing HF approval for merging

Hi @rashigupt and @jackal1-66, thanks for the huge work and sorry for the delay! I still have some comments on this PR that I list here below.

1. Why do you trigger on the light quark rather than on the hadron you desire? First, triggering on a light quark is equivalent to trigger on each event, but then in the code you still apply a gap of 5 if I am not mistaken. Second, it is possible to trigger on a specific hadron without a dedicated external generator by adding a [TriggerExternal] in your .ini file, which seems to me to be closer to what you want to obtain from this production. This requires a macro similar (not the same) to this one, in which you set the PDG id of the hadrons you want to trigger on
2. I think that turning off all charm decays can introduce a bias in your production, I would suggest to turn them on and select pion and eta not from HF decays at the analysis level.

hi @stefanopolitano , Thank you for your comments.

1. Our physics goal is to enhance pion and eta production, therefore a hadron-level trigger is indeed required. In this context, we would like to ask whether it is acceptable to replace the light-quark triggers (u, d, s) in the same file (generator_pythia8_gaptriggered_nonhfe.C) with hadron triggers (π⁰ and η) in order to achieve the desired enhancement, instead of triggering on light quarks.
2. Furthermore, we would like to understand how switching off heavy-flavour (charm) production or decays at the generator level could introduce a bias, given that our goal is to evaluate the electron reconstruction efficiency for electrons originating from pion and eta Dalitz decays.

Hi @rashigupt, I think what you are describing in your point 1. is exactly what is done in the case of an external trigger. Personally, I would suggest to go in that direction instead of having a dedicated generator, which at this point won't be used as generator but as a trigger. Regarding your second point, to me is quite strange to suppress HF decays. My naive expectation would be that if you turn them off you are biasing the topology of your events with respect to a realistic data taking. For instance, I would expect the multiplicity of your events to be smaller than the one obtained in a MC in which the HF hadrons are allowed to decay. Similarly, also the occupancy will be different, the resolution on the primary vertex, etc. Have you checked the impact of this choice on the reconstruction efficiency of pion and eta? In addition, by looking at previous analyses (https://alice-notes.web.cern.ch/system/files/notes/analysis/1172/2023-03-23-EHCorrelation_AN_pp_pPb_2021-1.pdf), it seems to me that the HF decays were considered, even when enhancing the pi0 and eta contributions.